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Abstract 

Software  designos  compose  systems  from  components  written  in  some  programming  language.  They  regularly 
describe  systems  using  abstract  paoems  and  sophisticated  relations  among  components.  However,  the  configuration 
tools  at  their  (fiqx>sal  restrict  them  to  composition  mechanisms  directly  supported  by  the  programming  language. 
To  remedy  this  lack  of  expressiveness,  we  must  elevate  the  relations  among  components  to  rirst*class  entities  of  the 
system,  entitled  to  their  own  specifications  and  abstractions. 
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Architectural  descriptions  treat  software  systems  as  compositions  of  components.  They  fo¬ 
cus  on  the  components,  leaving  the  description  of  interactions  among  these  components 
itxq>licit,  distributed,  and  difficult  to  identify.  If  the  interfaces  to  the  components  are  explicit, 
they  usually  ccmsist  of  impon/export  lists  of  procedures  and  data.  Interactions  are  expressed 
implicitly  through  include  files  or  import  and  export  statements,  together  with  the 
documentation  that  accompanies  various  libraries.  This  view  of  software  architecture  orga¬ 
nizes  information  around  the  components  and  ignores  the  significance  of  interactions  and 
connections  among  the  modules. 

This  paper  begins  by  discussing  the  limitations  of  the  conventional  approach  to  system  con- 
figuraticm.  It  then  argues  that  designers  must  attend  as  carefully  to  connecdcxis  among  com¬ 
ponents  as  to  the  components  themselves.  It  closes  by  proposing  a  model  of  system  com¬ 
position  in  which  connectors  are  first-class  entities  along  with  components.  Section  1  sum¬ 
marizes  current  practice  and  Sectitm  2  describes  some  of  the  resulting  difficulties.  Section  3 
gives  a  fresh  view  of  system  ccmfiguration  and  Section  4  sketches  a  language  to  support  that 
view. 

1 .  Current  practice 

When  a  designer  writes  a  paper  about  a  software  system,  the  first  section  often  includes  a  di¬ 
agram  and  a  few  paragraphs  of  text  labeled  the  “software  architecture.”  The  text  refers  in¬ 
formally  to  common  software  notions  such  as  pipelines,  client-s^er  relations,  interpreters, 
message-passing  systems,  and  event  handlers.  The  diagram  usually  consists  of  boxes  and 
lines,  but  the  semantics  of  the  graphic  elements  varies  substantially  from  one  figure  to  an¬ 
other  [5].  Figure  1  is  typical  of  these  figures.  It  depicts  a  sequence  of  three  processing  steps 
in  which  the  second  step  also  uses  four  abstract  data  types  and  communicates  in  various 
ways  with  a  satellite,  an  interactive  workstation,  and  a  database.  The  components  depicted 
in  Ae  diagram  may  have  substructure,  but  ultimately  the  implementations  of  the  components 
must  be  written  in  conventional  programming  languages. 


Figure  1:  Typical  box-and-line  depiction  of  a  software  architecture 


Sometimes  components  have  explicit  interface  definitions.  These  define  the  external  struc¬ 
ture  of  the  components.  They  usually  consist  of  lists  of  procedures,  exponed  data,  and  per- 
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haps  types,  exceptions,  etc.  Ada’s  specification  parts  and  C’s  .  h  files  are  examples 
of  such  interface  definitions.  Interfaces  do  not  aggregate  these  details  to  reflect  the  more  ab* 
stract  relations  they  implement.  The  specifications  of  functionality,  if  any,  are  generally 
written  in  prose;  formal  specifications  that  provide  details  beyond  type  and  signature  are 
relatively  rare. 

In  these  conventional  designs,  all  modules  have  equal  status.  That  is,  they  are  undifferenti¬ 
ated  collections  of  procedures,  data,  and  other  constructs  of  the  underlying  programming 
language.  Nothing  analogous  to  a  type  system  indicates  that  a  module  has  special  properties, 
discriminates  among  different  kinds  of  modules,  or  identifies  speci^c  Idnds  of  analysis 
available.  In  the  associated  implementations,  import  and  export  statements  in  each 
module  establish  the  dependencies  among  modules.  In  Ada  these  are  uses  clauses;  in  C 
they  are  includes.  Specific  associations,  for  example  between  a  procedure  definition  and 
its  call,  rely  on  matching  the  names  at  the  definition  and  use  sites. 

The  noodels  implicit  in  designers’  architectural  descriptions  (both  text  and  diagrams)  do  not 
match  the  actual  realization  of  these  models  in  code:  Architectural  models  are  rich,  abstract, 
spontaneous,  and  almost  wholly  informal.  However,  the  implementation  languages,  includ¬ 
ing  module  interconnection  languages,  are  rigorous,  precisely  defined,  and  limited  in 
expressiveness  to  the  constructs  of  the  underlying  programming  language. 

As  a  result  of  these  mismatches,  the  code  fails  to  capture  designers’  intentions  for  the  soft¬ 
ware  explicitly  and  accurately  and  precise  design  documentation  does  not  persist  into  mainte¬ 
nance.  This  impedes  immediate  checking  and  future  guidance  for  development  and  mainte¬ 
nance  activities.  Even  insofar  as  the  code  actually  captures  parts  of  the  design,  it  does  so  in  a 
highly  distributed  fashion,  and  it  is  hard  for  a  reader  to  get  a  system-level  overview.  The 
need  to  address  abstractions  for  system  configuration  is  becoming  widely  recognized  [3,  5, 
6,  9,  10]. 

2 .  Problems  with  current  practice 

Current  practice  in  architectural,  or  system-level,  design  focuses  on  components.  For  a 
system  to  work  well,  however,  the  relations  among  components,  or  connectors^  require  as 
much  design  and  develt^ment  attention  as  the  components. 

Connectors  are  less  obviously  objects  of  design  than  are  components.  After  all,  the  connec¬ 
tors  often  do  not  have  code — hence  identity — of  their  own.  They  may  be  realized  in  dis¬ 
tributed  fashion  by  a  variety  of  system  mechanisms.  Indeed,  system  mechanisms  such  as 
ccxmnon  scheduling  and  synchronization  policies  or  the  available  communications  protocols 
may  constrain  tiie  designers’  choices.  Many  of  the  problems  with  current  techniques  for  ar¬ 
chitectural  definition  revolve  around  inadequacies  of  the  mechanisms  for  defining  continent 
interconnection. 

This  section  reviews  some  of  the  problems  with  the  conventional  approach  of  embedding  the 
interactions  among  compcxients  within  the  components. 
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2.1.  Inability  to  localize  information  about  interactions 

Most  current  module  interconnection  techniques,  including  programming  languages  such  as 
Ada,  depend  on  import  and  export  commands  lodged  in  the  code  modules  of  the  system  [4, 
7].  A  link  editor  then  connects  the  components  by  matching  the  names  of  exponed  and  im¬ 
ported  constructs,  possibly  with  guidance  from  the  import  and  export  statements  about 
the  scope  of  names.  This  has  three  major  problems 

•  Forced  agreement  in  spelling:  The  importer  must  use  the  same  name  as  the  exporter.  In 
at  least  one  case,  a  “reusable”  library  was  not  usable  because  its  names  conflicted  with 
existing  names  of  a  system. 

•  Dispersion  cf  structural  informanon:  An  impon/export  strategy  distributes  structural  in¬ 
formation  throughout  the  system.  This  hides  the  system  structure  and  impedes  reuse  by 
creating  embedded  references  to  other  components. 

•  Forcedasymmetry  of  interaction:  The  import/export  model  assumes  asymmetrical  rela¬ 
tions — there  must  be  an  owner  and  a  user,  or  a  master  and  a  slave,  or  a  source  and  a 
destination.  Although  many  interactions  are  binary  and  asymmetrical,  not  all  are:  peer- 
to-peer  communication  is  symmetrical,  client-server  relations  can  have  multiple  com¬ 
ponents  in  each  role. 

Current  practice  is  also  unable  to  localize  the  related  abstractions.  There  is  no  natural  home 
for  the  definitions  that  govern  a  class  of  interactions.  Interactions  are  provided  and  deflned 
by  the  operating  system,  the  programming  language,  subroutine  libraries,  embedded  lan¬ 
guages,  and  ad  hoc  user-defined  mechanisms.  Giving  legitimate,  uniform  status  to  defrni- 
titMis  of  interactions  would  improve  system  understanding  and  analysis. 

2.2.  Poor  abstractions 

Boxes,  lines,  and  adjacency  don’t  have  consistent  meaning  across  system  structure  dia¬ 
grams.  They  usually  represent  abstract  intenu:tions  rather  than  the  procedure  calls  and  data 
declarations  of  the  code.  Practical  systems  have  quite  sophisticated  rules  about  component 
interaction  and  shared  representations.  Existing  defrnition  mechanisms  don’t  allow  those 
design  decisions  to  be  captured  in  the  code,  so  they  can’t  be  exploited  for  analysis  or  mainte¬ 
nance.  The  abstractions  are  hidden  for  several  reasons; 

•  Inability  to  associate  related  elemenis  and  name  the  cluster:  A  module  interface  may  ex¬ 
port  a  l»ge  number  of  named  elements.  Apan  from  comments — ^which  have  no  force — 
there  is  no  good  way  to  declare  that  a  set  of  these  elements  behaves  as  a  coordinated 
group.  Further,  there  is  no  way  to  name  the  cluster  for  reference  as  a  whole. 

•  Inability  to  specify  relations  among  related  elements:  The  ordering  and  state  consistency 
requirements  among  a  coherent  set  of  calls  are  usually  implicit.  This  is  almost  in¬ 
evitable,  fex-  there  is  no  logical  place  to  state  them. 

•  Inability  to  specify  aggregate  properties  of  a  collection  of  elements:  Even  without  ex¬ 
plicit  names,  practietd  systems  have  quite  sophisticated  rules  about  protocols  and  shared 
representations.  Individual  procedure  and  data  element  specifications  localize  informa¬ 
tion  and  are  not  adequate  to  express  these  relations. 

In  Figure  1,  shapes  help  the  reader  differentiate  among  different  kinds  of  components,  even 
thou^  the  programming  language  and  rrxxlule  interconnection  language  may  not  support  the 
distinctions.  However,  all  the  connections  in  that  frgure  are  represented  in  the  same  way — 
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as  simple  lines.  Figure  2  shows  an  improved  drawing,  with  different  line  textures  denoting 
different  kinds  of  interactions. 

Designers  have  abstract,  sophisticated  intentions  for  the  relations  among  components. 
However,  they  have  no  reasonable  way  to  capture  these  design  intentions  as  a  permanent 
part  of  the  software.  Even  worse,  the  abstract  relations  are  almost  always  realized  as  se¬ 
quences  of  procedure  calls  embedded  in  modules  whose  ostensible  function  is  something 
entirely  different.  Usual  practice  does  not  identify  the  abstract  functions  of  the  procedure 
calls,  nor  does  it  explain  the  rules  about  required  order  of  operations. 


Figure  2:  Revised  architecture  diagram  with  discrimination  among  connections 

2.3.  Lack  of  structure  on  interface  definitions 

As  noted  above,  we  lack  a  widely-used  notation  for  structuring  interface  deHnitions  so  that 
they  cluster  coherent  subsets  of  operations.  In  practice,  though,  a  module  is  likely  to  have 
interfaces  for  one  or  more  sets  of  primary  users  (to  provide  the  overt  system  function)  and 
additional  special  operations  for  such  special  uses  as  audit  trails,  monthly  reports,  executive 
control  (setpoints  or  system  tuning),  system  initialization,  monitoring,  and  debugging. 
Monolithic  interfaces  can  neither  clarify  nor  enforce  these  distinctions. 

Two  levels  of  structure  and  abstraction  are  missing: 

*  Abstractions  for  connections:  aggregation  of  primitive  import/exports  to  show  the  in¬ 
tended  abstract  function  of  the  connection. 

•  Segmentation  of  interfaces:  decomposition  of  an  interface  into  more-or-less  conven¬ 
tional  segments  corresponding  to  different  groups  of  users  or  different  classes  of  func- 
tirxiality;  each  of  these  may  involve  several  abstract  connections. 

2.4.  Mixed  concerns  in  programming  language  specification 

Programming  languages  were  designed  to  describe  algorithmic  operations  on  data.  They  are 
very  good  at  defining  data  structures  and  algorithms  that  operate  on  those  data  structures. 
Extensions  allow  them  to  describe  computational  structures  such  as  concurrency.  They  are 
not  particularly  good  at  describing  reliabilify,  absolute  time,  and  a  variety  of  extra-functional 
pr{q)^es.  Nor  are  they  good  at  defining  interactions  among  other  monies  that  are  more 
abstract  than  procedure  calls  and  shared  data 
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Two  problems  result.  First,  all  interactions  not  directly  supported  by  the  programming  lan¬ 
guage  must  be  encoded  as  sequences  of  procedure  calls.  Second,  constructs  for  system 
composition  have  been  grafted  onto  programming  languages,  with  less  than  ideal  results 
(e.g.,  private  parts  of  Ada). 

The  concerns  of  architectural  design  are  not  with  algorithms  and  data  structures,  but  rather 
with  system  topology,  assignment  of  capability  to  components,  interactions  among  compo¬ 
nents,  and  performance  characteristics.  Therefore  it  is  unrealistic  to  expect  conventional 
programming  languages  to  serve.  Much  of  the  current  awkwardness  seems  to  arise  from  at¬ 
tempts  to  add  capabilities  to  conventional  programming  languages  that  stretch  them  beyond 
their  design  limits. 

2.5.  Poor  support  for  components  with  incompatible  packaging 

When  multiple  components  are  reused — ^for  example  from  different  libraries — their  interfaces 
do  not  always  mesh  well,  even  if  their  computational  capabilities  are  substantially  compati¬ 
ble.  For  example, 

•  If  a  component  is  cast  as  a  filter,  it  can’t  be  used  as  procedure  because  it  does  I/O  to 
pipes  instead  of  through  procedure  parameters. 

•  If  a  ccxnponent  is  cast  interactively,  it  often  can’t  be  called  by  another  program. 

•  If  semantics  are  suitable  but  packa^ng  details  such  as  name  and  parameter  order  differ, 
the  user  must  write  ad  hoc  conversions. 

Something  akin  to  typing  is  going  on  here:  to  use  a  component,  you  need  to  know  not  only 
what  it  computes  but  also  how  it  delivers  that  computation.  In  many  of  these  cases,  the  in¬ 
compatibilities  can  be  overcome  by  introducing  mediators  that  accommodate  discrepancies 
between  the  protocol  expected  by  the  component  and  the  protocol  requested  by  the  designer. 

2.6.  Poor  support  for  multi-language  or  multi-paradigm  systems 

The  cotmection  between  components  is  substantially  independent  of  the  programming  lan¬ 
guages  of  the  components.  For  example,  this  is  usually  the  case  when  the  components  run 
as  separate  processes.  Connectors  that  work  naturally  in  these  cases  include  unix  pipes  and 
many  message  systems. 

In  other  cases,  the  connection  between  components  depends  directly  on  the  programming 
language.  This  is  often  the  case  when  components  share  assumptions  about  runtime  systems 
such  as  representations  of  data  types. 

The  ccHiditions  under  which  components  in  different  languages  can  interact  musts  be  detailed 
in  such  a  way  that  a  system  development  tool  can  tell  which  connections  are  allowable, 
which  can  be  mediated,  and  which  cannot  be  supported. 

Furthermore,  tools  intended  to  support  one  architectural  paradigm — object  management 
tools,  Unix  shell — offer  little  assistance  in  creating  a  system  that  mixes  different  architectural 
idioms. 

2.7.  Poor  support  for  legacy  systems 

Most  software  development  now  involves  modification  of  existing  systems.  Most  of  these 
systems  evolved  without  configuration  tools  any  more  sophisticated  than,  say,  make. 
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Syntactic  tools  make  it  possible  to  extract  the  signatures — the  names  and  types  of  imported 
and  exported  entities.  However,  they  offer  no  help  in  recovering  the  higher-level  intentions 
such  as  which  set  of  procedures  collectively  implements  a  given  abstract  protocol.  Over  half 
of  system  maintenance  effort  goes  into  deciphering  what  the  software  already  does,  so  the 
inability  to  record  and  retain  the  designer’s  higher-level  intentions  about  component  interac¬ 
tions  is  a  major  cost  generator. 

3 .  A  fresh  view  of  software  system  composition 

Systems  are  composed  from  identifiable  components  of  various  distinct  types.  The  compo¬ 
nents  interact  in  identifiable,  distinct  ways.  Components  roughly  correspond  to  compilation 
units  of  conventional  programming  languages.  Connectors  mediate  interactions  among 
components;  that  is,  they  establish  the  rules  that  govern  component  interaction  and  specify 
any  auxiliary  mechanism  required.  Connectors  do  not  in  general  correspond  individually  to 
conq>ilation  units;  they  manifest  themselves  as  table  entries,  instractions  to  a  linker,  dynamic 
data  structures,  system  calls,  initialization  parameters,  servers  that  support  multiple  inde¬ 
pendent  connections,  and  the  like. 

It  is  helpful  to  think  of  the  connector  as  defining  a  set  of  roles  that  specific  named  entities  of 
the  components  must  plt^. 

Software  systems  thus  comprise  two  kinds  of  distinct,  identifiable  entities:  components  and 
connectors. 

•  Components  are  the  locus  of  computation  and  state.  Each  component  has  an  interface 
specification  tiiat  defines  its  properties.  These  properties  include  the  signatures  and 
toctionality  of  its  resources  together  with  global  relations,  performance  properties,  etc. 
Each  is  of  some  type  or  subtype  (e.g.,  filter,  memory,  server).  The  specific  named 
entities  visible  in  the  interface  of  a  component  are  its  players. 

•  Connectors  are  the  locus  of  relations  anx>ng  components.  They  mediate  interactions  but 
are  not  “things”  to  be  hooked  up  (they  are,  rather,  the  hookers-up).  Each  connector  has 
a  protocol  specification  that  defines  its  properties.  These  properties  include  rules  about 
the  types  of  interfaces  it  is  able  to  mediate  for,  assurances  about  properties  of  the  inter¬ 
action,  rules  about  the  order  in  which  things  happen,  and  commitments  about  the  inter¬ 
action  such  as  ordering,  performance,  etc.  Each  is  of  some  type  or  subt]^  (e.g.,  re¬ 
mote  procedure  caU,  pipeline,  broadcast,  event).  The  specific  named  entities  visible  in 
the  protocol  of  a  connector  are  roles  to  be  satisfied  (e.g.,  client,  server). 

Conqxments  may  be  either  primitive  or  composite.  Primitive  components  are  usually  code  in 
the  conventional  programming  language  of  your  choice.  Composite  components  define 
configurations  in  a  notation  independent  of  conventional  programming  languages.  This  no- 
taticm  must  be  able  to  identify  the  constituent  components  and  connectors,  match  die  coimec- 
tion  points  of  components  with  roles  of  connectors,  and  check  that  the  resulting  composi¬ 
tions  satisfy  the  specifications  of  both  the  components’  interfaces  and  the  connectors’ 
protocols. 

Similarly,  connectors  may  be  either  primitive  or  composite.  They  are  of  many  different 
kinds:  shared  data  representations,  remote  procedure  calls,  data  flow,  document  exchange 
standards,  standardize  network  protocols.  The  set  is  rich  enough  to  require  a  taxonomy  to 
show  relations  among  similar  kinds  of  connectors.  Primitive  connectors  may  be  imple- 
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mented  in  a  number  of  ways:  as  built-in  mechanisms  of  programming  languages  (e.g.,  pro¬ 
cedure  calls  associated  by  a  linker);  as  system  functions  of  the  operating  system  (e.g.,  certain 
kinds  of  message  passing);  as  library  code  in  conventional  programming  languages  (e.g., 
X/Motif);  as  shar^  data  (e.g.,  Fortran  common  or  Jovial  COMPOOL);  as  entries  in  task  or 
routing  tables;  as  a  combination  of  library  procedures  and  a  single  independent  process  for 
the  connector  (e.g.,  certain  kinds  of  communication  services);  as  interchange  formats  for 
static  data  (e.g.,  RTF);  as  initialization  parameters  (e  g.,  process  priority  in  a  real-time  op¬ 
erating  system)  and  probably  in  a  variety  of  other  ways.  Composites  may  also  appear  in 
these  Averse  forms;  we  need  (but  do  not  yet  have)  ways  to  define  them,  as  well. 

Connectors  are  properly  treated  separately  from  components  because; 

•  Connectors  may  be  quite  sophisticated^  requiring  elaborate  definitions  and  complex 
specifications  that  deserve  their  own  homes.  In  many  cases,  no  single  component  is  the 
appropriate  location  for  a  protocol  specitication. 

•  The  definition  of  a  connector  should  be  localized.  Just  as  good  methodology  requires  a 
single  location  for  the  definition  of  a  component,  good  methodology  requires  a  single 
location  for  the  definition  of  an  interaction.  This  supports  both  design  (especially  anal¬ 
ysis  during  design)  and  maintenance.  Further,  connectors  can  be  rich  enough  for  their 
definitions  to  deserve  their  own  homes. 

•  Some  information  about  the  system  does  not  have  a  proper  home  in  any  component. 
For  example,  in  a  real-time  system  it  may  be  appropriate  for  tasks  to  declare  their  needs 
and  fcK*  a  separate  scheduler  to  satisfy  theiiL 

•  Connectors  are  potentially  abstract.  They  may  be  parameterizable.  They  may  define 
classes  of  interactions  that  require  additional  scripting  at  the  time  of  instantiation.  Users 
may  wish  to  define  their  own  connectors,  to  make  their  own  specializations,  of  existing 
connectors,  or  to  compose  their  own  connectors.  A  single  connector  may  be  instanti¬ 
ated  multiple  times  in  a  single  system;  for  example,  a  multicast  capability  could  support 
many  distinct  sets  of  communicating  processes. 

•  Connectors  may  require  distributed  system  support:  The  mechanism  required  by  a 
connector  is  not  always  localized  to  individual  uses.  For  example,  a  message  passing 
system  may  require  exactly  one  server  per  processor  for  any  number  of  communicating 
processes. 

•  Components  should  be  independent.  The  interface  specification  of  a  component  should 
provide  a  complete  specification  of  the  capabilities  of  that  component  but  remain  silent 
on  how  it  is  actually  used. 

•  Connectors  should  be  independent.  A  single  (high-level)  connector  might  mediate 
relations  for  a  dynamically  changing  set  of  components.  Wiederhold  describes  such  a 
scheme  [11]. 

•  Relations  among  components  are  not fixed.  A  component  may  be  capable  of  being  used 
differently  by  <^erent  kinds  of  connectors.  For  example,  a  client  might  be  indifferent 
to  whether  its  saver  is  dedicated,  shared,  or  distributed.  In  addition,  system  connectiv¬ 
ity  can  change  dynamically. 

System  compositions  quite  frequently  reuse  patterns  of  composition;  some  of  these  patterns 
are  commonly  understood,  at  least  intuitively:  pipe/filter,  client/server,  layered  system, 
blackboard.  These  common  idioms  can  be  defined  as  generic  patterns  that  restrict  the  types 
of  cmnponents  and  connectors  to  be  used  and  describe  how  the  pattern  is  implemented  [5]. 
This  may  involve  constraining  the  topologies  of  interconnection.  Current  module  interconn¬ 
ection  languages  are  wholly  inadequate  to  this  task  for  reasons  elaborated  in  Section  2. 
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4.  An  architectural  language  with  first-class  connectors 

Software  system  composition  involves  different  tasks  from  writing  modules:  the  system  de¬ 
signer  defines  roles  and  relationships  rather  than  algorithms  and  data  structures.  These  con¬ 
cerns  are  sufficiently  different  to  require  separate  languages.  The  architectural  language  must 
support  syston  configuration,  independence  of  entities  (hence  reusability),  abstraction,  and 
analysis  of  properties  ranging  from  functionality  to  security  and  reliability  [9].  The  design  of 
such  a  language  is  not  straightforward.  In  addition  to  having  a  syntax,  it  must: 

•  Define  semantics  fra*  connectors  and  their  compositions. 

•  Genraalize  the  import/export  rules  to  address  asymmetry,  multiplicity,  locality, 
abstraction,  and  naming. 

•  Establish  type  structures  for  system  organizations,  components,  connectors,  and  the 
primitive  units  of  association  of  these  elements;  this  includes  defining  taxonomies  fra 
die  types. 

•  Set  out  appropriate  rules  for  architectural  abstractions. 

This  section  contains  some  initial  notes  on  these  language  design  problems. 

4.1.  Language  structure 

As  suggested  above,  the  language  needs  separate  (but  parallel)  constructs  for  components 
and  connectors.  It  must  provide  notations  for  composition  and  a  set  of  primitives  (including 
primitives  defined  in  conventional  programming  languages).  For  simplicity,  the  constructs 
for  components  and  connectors  can  be  similar.  Figure  3  suggests  the  essential  character  of 
the  language.  Each  construct  is  typed.  It  has  a  specification  part  and  an  implementation  part 
The  specification  part  defines  specific  units  of  association  to  be  used  in  system  composition. 

Element  Component  Connector 


Specification 

^  interface  ^ 

^  Protocol  ^ 

Type 

Component  Type 

Connector  Type 

Unit  of  association 

Player 

Role 

Implementation 

Implementation 

L  i 

Implementation 

y  y 


Figure  3:  Gross  structure  of  an  architecture  language 

It  is  sometimes  useful  to  say  explicitly  that  an  element  is  primitive;  this  means  that  it  is  not 
further  defined  at  the  architecture  level  but  is  implemented  in  a  programming  language  or 
witii  system-level  mechanisms. 

For  a  nonprimitive  element,  the  implementation  part  consists  of  a  pans  list,  composition  in- 
structicms,  and  related  specifications.  This  establishes  explicit  associations  and  specification 
matches,  tiiereby  breaking  free  of  name  matching  as  the  sole  means  of  making  connections. 

The  specifications  should  be  *‘open”  with  respect  to  construction  and  analysis  tools.  Many 
different  iqtproaches  are  available  fra  specifying  and  verifying  system  properties  of  interest; 
the  languages  should  be  able  to  accept  those  as  uninteipreted  expressions  and  interact  appro¬ 
priately  with  the  specialized  tools. 
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4.2.  Connectors  and  their  semantics 

Most  programming  languages  support  some  sort  of  intermodule  connection.  It  usually  sup¬ 
ports  only  the  primitive  units  of  association  of  the  language,  such  as  procedure  calls. 
Making  the  connectors  first-class  requires  careful  analysis  of  all  the  roles  these  constructs 
play  in  the  definition  of  a  systetiL 

A  connector  mediates  the  interaction  of  two  or  more  components.  It  is  not  in  general  imple¬ 
mented  as  a  single  unit  of  code  to  be  composed.  The  previous  section  describes  a  number  of 
the  implementation  possibilities.  Whatever  the  implementation  of  a  connector  (especially  an 
abstract  one),  detail  about  the  implementation  technique  is  encapsulated  when  the  connector 
is  used.  Moreover,  many  or  all  connectors  of  the  same  type  may  share  the  same  code  or 
data.  Allen  is  investigating  formal  specifications  of  the  semantics  of  certain  classes  of 
connectors  [1]. 

Like  components,  connectors  require  specifications.  Specifications  for  connectors  are  called 
protocob.  Since  protocols  can  be  of  many  different  kinds,  languages  should  allow  for  flex¬ 
ible  specifications.  One  possibility  is  heavy  use  of  property  lists,  with  some  standard  at¬ 
tributes  and  some  attributes  specific  to  particular  connector  types.  This  allows  for  properties 
as  diverse  as; 

•  guarantees  about  delivery  of  packets  in  a  communication  system 

•  ordering  restrictions  on  events  using  traces  or  path  expressions 

•  incremental  ptoduction/consumption  rules  about  pipelines 

•  distinguishing  between  the  roles  of  clients  and  servers 

•  parameter  matching  and  binding  rules  for  conventional  procedure  calls 

•  restrictions  on  parameter  types  that  can  be  used  for  remote  procedure  calls 

Primitive  coimectors  include  at  least  the  ones  directly  supported  by  the  programming  lan¬ 
guage  or  operating  system.  These  certainly  include  the  procedure  call  and  data  accessors  of 
each  programming  language;  they  also  include  language-specific  process  interactions  such  as 
the  Ada  rendezvous.  Careful  attention  to  the  roles  involved  in  primitive  connectors  show 
the  need  to  support  asymmetry:  a  procedure  has  a  definer  and  multiple  callers;  data  has  an 
owner  and  multiple  users.  On  the  other  hand,  in  certain  classes  of  event  systems  all  entities 
are  equally  entitled  to  generate  and  recognize  events,  so  it  is  also  necessary  to  define  sym¬ 
metric  roles  in  a  protocol.  The  usual  import/export  or  provides/requires  relation  is  too 
restrictive. 

The  surliest  kind  of  abstract  connector  is  binary  (its  protocol  has  two  roles,  far  example  de¬ 
finer  and  user).  Some  of  these  are  direct  analogs  of  the  language-supported  connectors, 
such  as  procedure  call.  At  the  architecture  level  the  relation  is  often  more  abstract.  For  ex- 
anqile,  it  may  be  desirable  to  separate  from  the  definition  of  a  procedure  the  decision  about 
whether  it  is  to  be  a  local  or  remote  procedure  call. 

N-ary  connectors  that  involve  multiple  components  are  also  important.  These  may  be  sym¬ 
metrical,  with  all  connected  components  playing  the  same  role  (e.g.,  multicast).  They  may 
(probably  more  commonly)  be  asymmetrical,  with  different  roles  for  different  components  or 
sets  of  components  (e.g.,  client-server  systems). 
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Connectors  are  often  implemented  as  sets  of  procedures.  A  set  of  procedures  frequendy  has 
an  associated  set  of  rules  or  assumptions  about  how  the  procedures  will  be  used.  These 
rules  are  often  highly  implicit  They  may  restrict  the  order  in  which  procedures  are  called  or 
require  relations  among  parameter  values.  These  rules  amount  to  protocols  for  the  interac¬ 
tion.  For  example,  the  operations  of  an  abstract  data  type  are  used  as  a  bundle;  they  often 
have  order  restrictions  such  as  “initialize  must  be  called  before  anything  else;  push  must  be 
called  at  least  as  often  as  pop.”  Explicit  restrictions  may  be  expressed  in  various  ways,  as 
path  expressions  or  traces  for  execution  order  restrictions.  Although  it’s  not  conventional,  it 
is  usefid  to  think  of  abstract  data  types  as  having  a  protocol  that  guides  the  use  of  the  opera¬ 
tions.  This  not  only  captures  essentials  such  as  execution  order  restrictions  but  also  decou¬ 
ples  the  selection  of  the  abstract  type  from  the  selection  of  an  implementation.  This  is  not 
unlite  Larch’s  separation  between  abstract  properties  and  actual  implementations. 

Figure  4  suggests  the  protocols  required  to  construct  the  system  of  Figures  1  and  2.  These 
protocols  should  exist  as  independent  definitions  in  the  computing  environment.  They  may 
take  parameters  (including  partial  specifications)  and  may  support  several  variants.  When 
they  are  used,  additional  specifications  may  be  needed  to  specialize  the  protocol  or  select  a 
particular  form. 
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Protocol  X 
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Figure  4:  Constellation  of  protocol  specifications  required  by  example 


Figure  5  shows  some  of  the  information  that  should  be  in  the  interface  of  the  central  compo¬ 
nent  of  Figures  1  and  2.  This  syntax  is  suggestive  rather  than  definitive.  Annotations  on  the 
left  side  show  correspondences  to  the  line  styles  of  the  diagram.  Each  of  the  nine  lines  of  the 
interface  describes  an  interaction  with  some  other  component. 


Central 

pipe  in  A ...  <speo ... 
p/pe  out  8 ...  <spec> ... 
data  link  C  protocol  X ...  <speo ... 
Xwindow  D  typescript 


uses  ADT 
uses  ADT 
uses  ADT 
uses  ADT 


E1,E2,E3}spec  Gorp 
F1,F2}  spec  Thud 
G1,G2,G3}  spec  Foo 
H1,H2,H3}  spec  Baz 


accesses  DB  {Q1  ,Q2,Q3.Q4}  protocol  Y 


Figure  5:  Interface  specification  of  central  component,  referring  to  protocols 
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Note  that  in  several  cases  the  normal  notion  of  exporting  some  resources  and  importing  oth¬ 
ers  does  not  apply  well.  For  the  pipes,  additional  specifications  limit  the  type  of  information 
passing  through  the  pipe.  Similarly,  a  communication  protocol  may  require  additional  spec¬ 
ifications.  The  four  abstract  data  types  are  all  of  the  same  general  category  of  protocols;  the 
bracketed  names  are  the  names  by  which  the  central  component  will  call  designated  opera¬ 
tions  of  the  four  types. 

4.3.  Architectural  type  structures 

A  problem  akin  to  type  checking  arises  at  three  points  in  an  architectural  language.  Two  ap¬ 
pear  in  the  preceding  discussion;  the  types  of  components  and  of  connectors.  As  with  any 
type  system,  these  express  the  designer’s  intent  about  how  to  use  the  element  properly.  To 
be  useful,  they  must  also  have  some  enforcement  power. 

Architectural  types  describe  expected  capabilities.  They  can  limit  the  legitimate  ways  to  use 
the  construct.  They  can  abbreviate  restrictions  on  what  can  appear  in  the  constmct’s  specifi¬ 
cation.  Examination  of  real  systems  shows  that  type  hierarchies  of  this  sort  are  useful.  For 
example,  there  are  many  kinds  of  memories  (components)  and  many  kinds  of  event  systems 
(connectors).  Defining  type  structures  for  these  elements  requit'  ;  creation  of  taxonomies 
that  catalog  and  structure  the  type  variations. 

The  third  place  where  something  like  type  checking  shows  up  is  at  the  actual  point  of  asso¬ 
ciating  players  of  components  with  roles  of  connectors.  Each  of  the  named  entities  in  the 
interfaces  (of  components)  and  protocols  (of  connectors)  must  have  enough  type  and  other 
specification  to  check  on  whether  the  connector  definition  allows  the  components  to  be  as¬ 
sociated  as  requested. 

Because  of  the  need  m  reuse  components  and  connecters  in  settings  that  aren’t  all  quite  alike, 
it  is  inqwrtant  to  deal  reasonably  with  as^iations  that  don’t  quite  match.  A  very  common 
exanq)le  is  the  use  of  a  unix  pipe  to  send  data  to  a  file.  The  definition  of  a  unix  filter  will 
probably  say  it’s  intended  to  interact  with  other  filters  through  pipes.  However,  it  is  often 
(Init  not  always)  well-defined  to  substitute  a  file  (passive  component)  for  a  filter  (active  com¬ 
ponent).  The  language  must  provide  a  way  to  define  and  control  possible  fix-ups,  for  ex¬ 
ample  by  suppOTting  rules  of  the  flavor  “this  pipe  will  accept  a  file  in  the  role  of  filter  under 
the  following  circumstances ...”.  Some  of  the  interesting  altonatives  include: 

•  Associate  anyhow:  it  will  work  without  extra  effort  (some  subtype  relations). 

•  Rearrange  or  reformat  information  (data  re-fmmatters  [2],  parameter  re-mappos  [8]). 

•  Wrap  the  component  in  a  convener  (a  procedure  wrapper  for  a  filter  would  feed  the  in¬ 
put  parameters  to  the  input  pipe  of  the  filter  and  collect  the  result  ftom  the  output  pipe 
for  delivery  as  a  single  value). 

•  Comcn  data  to  and  from  a  shared  form  (interchange  format). 

•  Convert  data  of  one  component  to  the  form  expeaed  by  another  (pairwise  compatibility; 
common  message  format,  but  data  may  need  to  be  interpreted). 

•  Insert  conversion  nuxlule  (cuffer). 

•  Just  say  no. 
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The  history  of  type  cowcion  in  conventional  programming  languages  (especially  PL/I)  pro¬ 
vides  convincing  evidence  that  this  capability  must  remain  firmly  under  control  of  the 
software  deagner  at  all  times. 

A  special  case  of  compatibility  checking  and  enforcement  arises  when  components  are  writ¬ 
ten  in  different  programming  languages.  The  difficulty  of  accomplishing  this  depends  on  the 
extent  of  the  shared  assumptions  between  the  components. 

•  Stxnetimes  there  is  no  problem:  One  common  easy  case  when  two  languages  share  run¬ 
time  systems  with  common  runtime  representations,  procedures,  and  ocols 
(Fortran/Snobol).  A  second  common  case  is  explicit,  loosely-coupled  intera  (unix 
pipes  with  ASCII  streams). 

•  Smnetimes  the  problem  can  be  resolved  with  mediation  as  described  above. 

•  Sometimes  an  external  representation  standard  (RTF,  PKTT,  SYLK)  or  an  inter-lan¬ 
guage  procedure  call  can  serve  as  a  cross-language  connector. 

•  Sometimes  it’s  simply  too  hard  (languages  with  essentially  different  assumptions:  rule- 
based;  static  imperative;  dynamic). 

4.4.  Abstractions  for  higher-level  connectors 

The  discussion  so  far  has  mentioned  many  different  higher-level  connectors.  These  include 
client/server  relations,  messages,  event  Imdlers,  multicast  communication,  radio  communi¬ 
cation  links,  Unix  pipes,  shared  data,  interaction  through  X/Motif  or  SQL  scripts,  hierarchi¬ 
cal  layers,  and  blackboards.  The  example  of  Figures  1  and  2  might  be  instantiated  with 
SQL,  X/Motif,  various  data  abstractions  with  usage  restrictions,  unix  pipes,  and  radio  data 
links.  The  software  development  environment  should  provide  the  most  common  of  these, 
either  as  part  of  the  programming  language,  as  basic  operating  system  capability,  or  as  part 
of  the  inffastructure  (SQL,  X/Motif).  Protocols  for  this  baseline  collection  should  be  primi¬ 
tive  to  the  architectural  language.  It  is  still  unclear  exactly  how  to  define  the  association  of 
procedure  calls  with  abstract  protocols  precisely,  and  the  semantics  of  abstract  connectors  are 
also  an  open  question  at  this  time.  However,  it  is  clear  that  connectors  have  interesting  in¬ 
ternal  structure,  much  as  unix  pipes  contain  buffers. 

As  discussed  in  section  2.3,  component  interfaces  often  have  several  distinct  segments  in  or¬ 
der  to  establish  different  kinds  of  relations.  Often  these  will  have  corresponding  protocols. 

An  architectural  language  must  support  not  only  individual  abstract  connectors,  but  also 
high-level  compositions  that  involve  a  number  of  connectors  in  specific  relations  to  one  an¬ 
other.  For  example,  the  language  must  be  capable  of  capturing  die  high-level  architectural 
idioms  such  as  blackboards,  interpreters,  and  various  domain-specific  architectures  as  ab¬ 
stractions.  I  conjecture  that  non-primitive  connectors  are  the  appropriate  way  to  do  this,  but 
it  isn’t  yet  demonstrated. 

5.  The  promise  of  explicit  architectural  notations 

What  makes  the  constroction  of  composable  systems  different  from  conventional  program¬ 
ming?  First,  con^sing  a  system  from  subsystems  is  unlike  progranuning  the  algorithms 
and  data  structures  that  lie  within  the  primitive  subsystems.  The  semantics  of  the  compo¬ 
nents,  tte  locality  of  reasoning,  the  character  of  interaction  with  other  components,  the  prcp- 
erties  of  interest,  and  the  nature  of  the  reasoning  are  all  different.  Second,  we  are  liberating 
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ourselves  fix>m  thinking  of  the  task  as  merely  “programming”.  We  are  not  n^rely  building  a 
program  that  receives  inputs,  executes,  and  terminates — we  are  building  a  system  that  has  an 
enduring  existence  in  some  larger  environment.  Third,  our  units  of  manipulation  are  not 
simply  conventional  modules  (which  might  export  data,  procedures,  and  pertiaps  tasks),  but 
radier  components  and  connectors. 

Identifying  connectors  as  first-class  entities  in  a  system  can  help  to  break  us  out  of  the  pro¬ 
gramming-language  mindblock  for  system  composition  languages.  Legitimizing  higher-level 
interactions  among  components  allows  us  to  understand  the  procedure  call  as  one — ^peiiiaps 
the  primary — primitive  connector  of  pairs  of  modules.  More  significantly,  it  allows  us  to 
recognize  higher-level  connectors  as  critical  to  system  design.  We  must  learn  to  support 
higher-level  connectors — composite  components  and  connectors  whose  properties,  ex¬ 
pressed  in  their  interface  and  protocol  specifications,  are  as  understandable  as  their 
constituents. 

The  view  pressed  in  Sections  3  and  4  addresses  the  problems  identified  in  Section  2. 

•  It  specifically  provides  for  localizing  information  about  interactions:  Nonprimitive 
components  can  invoke  rich  relations,  and  they  concentrate  structural  information. 

•  It  introduces  abstractions  for  interactions  and  provides  a  starting  point  for  user-defined 
abstractions  and  aggregations. 

•  It  partially  addresses  the  interface  structure  problem  by  using  the  roles  of  connectors  to 
identify  related  operations  as  players. 

•  It  separates  architectural  concerns  from  {nogramming  concerns  by  providing  different 
language  constructs  with  different  semantics. 

•  It  makes  provisions  for  a  type-checking  system  that  can  adapt  to  mild  mismatches, 
thereby  enhancing  opportunities  for  reuse. 

•  It  clarifies  the  cemditions  under  which  programming  languages  can  be  mixed. 

•  It  offers  prospects  for  improved  support  of  legacy  systems  by  making  the  architectural 
design  of  the  system  expUdt 

The  principled  use  of  compositional  structures  should  have  a  dramatic  effect  on  software 
production.  It  should  permit  the  choice  of  design  paradigms  to  match  desired  system  charac¬ 
teristics.  It  should  allow  the  development  of  application-specific  frameworks  and  reference 
architectures.  It  should  provide  the  basis  for  exploiting  compositional  properties  of  systems 
for  formal  analysis,  code  generation,  and  software  reuse.  It  should  support  a  high  level  of 
visible  abstraction  for  systems  designers  so  that  large  systems  can  be  more  easily  designed, 
understood,  maintained  and  enhanced.  It  should  enable  us  to  better  accommodate  old  code 
by  providing  ways  to  recover  partial  architectural  information  from  existing  systems. 
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